Routine PHP dependency refresh: bumps guzzlehttp/guzzle 7.13.2→7.14.0, guzzlehttp/promises 2.5.0→2.5.1, guzzlehttp/psr7 2.12.3→2.12.4, sabre/event 5.1.8→5.1.9, and roave/security-advisories (advisory-DB refresh). Only composer.lock and the changelog entry change.

Branch target

oC11 / master — in scope. ✓ (Author is @phil-davis, not Dependabot, so the Dependabot auto-merge fast-lane does not apply — this needs the normal human approval.)

Review passes

• Security: no findings, net-positive. All updated packages are permissive-licensed (guzzle* MIT, sabre/event BSD-3, roave MIT) — no GPL/AGPL, no replace local-path directives. roave/security-advisories moves forward and tightens conflict constraints (e.g. web-auth/webauthn-lib, egroupware/egroupware, code16/sharp), which strengthens CVE blocking rather than introducing one. No known CVE introduced by the guzzle/sabre bumps.
• Stability: no findings. Patch/minor bumps of mature libraries; no first-party code touched. PHP Unit passed on all 5 DB engines and the acceptance shards that completed were green.
• Performance: no findings.
• Test coverage: N/A for a lockfile-only change — no application code added, so the 85% gate does not apply.
• Dependabot coverage: .github/dependabot.yml covers the composer ecosystem at / (where composer.json / composer.lock live) — ✓ no gap.

CI status — red, but spurious (infra abort, not a regression)

The failing checks belong to CI run attempt #2 (a manual re-run), whose jobs all terminated with The runner has received a shutdown signal … operation was canceled during PHP setup, before any test executed — a GitHub Actions runner preemption, not a test or dependency failure. Attempt #1's PHP Unit (all 5 DBs) and the acceptance shards that ran were green, and license/cla is green.

Recommended action: re-run the CI workflow (Actions → run 28999405727 → "Re-run failed jobs"). I attempted the re-run automatically, but the review integration lacks actions:write permission (403 Resource not accessible by integration), so a maintainer needs to trigger it.

Quality gates

• Security: no findings
• Stability: no findings
• Performance: no findings
• Test coverage: n/a (lockfile-only change)
• TODOs found: none
• Dependency touched: yes — composer; confirmed covered in .github/dependabot.yml
• CI status: failing (CI attempt #2) — spurious runner-shutdown abort during setup, not a code failure; re-run recommended
• Stale review: no

Verdict

Commenting — no code findings; the only issue is a spurious CI runner abort. Re-run CI for a clean green. Already human-approved by @DeepDiver1975.

🤖 Automated review by Claude Code (security · stability · performance · coverage)

Generated by Claude Code

CI update — correcting my earlier review

Retraction: my previous review (08:46Z) characterized the red CI as a spurious runner shutdown during setup and recommended simply re-running for a "clean green." A re-run of workflow 28999405727 has since executed at ~10:55Z, and that characterization no longer holds — the jobs actually ran to completion and 3 acceptance suites failed for real (not setup aborts). Please do not merge on the strength of my earlier "just re-run it" note.

Verified CI state (latest attempt, run 28999405727)

• Failed (ran full duration, real failures):
  • API Tests / apiShareOperationsToRoot1,apiShareOperationsToRoot2 (ran ~25 min)
  • API Tests Federation / apiFederationToRoot1,apiFederationToRoot2
  • CLI Tests / cliBackground,cliMain,cliManageApps,cliTrashbin
• The remaining ~20 API shards show cancelled — that is fail-fast cancellation triggered by the above, not independent passes.
• license/cla: green. PHP Unit (attempt 1): green.

Root cause — not yet confirmed

I inspected the job logs but could not extract the behat scenario-level assertion (it sits above a very large trailing artifact dump). What I can say:

• The failures span three unrelated suites (sharing, federation, CLI) that all started in the same ~10:55Z runner batch — a pattern more consistent with shared-infra flakiness (runner/DB contention) than a single code regression.
• The Apache access logs I sampled show requests completing with normal status codes (200/201/207, plus expected 404s), i.e. no obvious GuzzleHttp 5xx/stack-trace signature — so there is no positive evidence yet of a guzzle/sabre regression, but it cannot be ruled out either.

Recommended next step (needs a maintainer — I lack actions:write)

1. Re-run the failed jobs once more. If all three go green, this was infra flakiness and the PR is clean.
2. If any suite fails again on a clean re-run, download the behat report artifact for that shard to get the failing scenario — a guzzle 7.13→7.14 / sabre-event 5.1.9 behavioral change reaching the federation/sharing HTTP paths would be the thing to check.

Because this is a dependency bump whose current failures touch federation and sharing (both escalate-to-human areas), I am not auto-fixing and not approving until CI is genuinely green.

Quality gates

• Security: no findings (dependency licenses permissive; roave advisory-DB tightened, not loosened)
• Stability: CI failing — 3 acceptance suites (sharing / federation / CLI) red on latest re-run; root cause unconfirmed (flaky-infra vs regression)
• Performance: no findings
• Test coverage: n/a (lockfile-only change)
• TODOs found: none
• Dependency touched: yes — composer; confirmed covered in .github/dependabot.yml
• CI status: failing — API Tests (apiShareOperationsToRoot), API Tests Federation (apiFederationToRoot), CLI Tests (cliMain et al.)
• Stale review: no

Verdict

Commenting — no code findings, but not mergeable while CI is red. Not the Dependabot fast-lane (author is @phil-davis). Needs a clean re-run and a human decision before merge.

🤖 Automated review by Claude Code (security · stability · performance · coverage)

Generated by Claude Code